try-runtime will enforce migration idempotency (if you add a try-runtime test, of course).

For non-storage-versioned migrations, I used this trick to make a migration idempotent: https://github.com/polkadot-fellows/runtimes/pull/178/files#diff-efa4caeb17487ecb13d8f5eb7863c3241d84afa2e73fbf25909a2ca89df0f362R1816-R1819

That needs a lot of care, but until we have paritytech/polkadot-sdk#2421 we don't have a better option AFAIK

@tdimitrov Just realized: We also should do this renaming on our testnets in polkadot-sdk.

Renaming a pallet turns out to be a tedious process:

1. The rename triggers a hook which believes a new pallet is added and sets its onchain version to the one in the code automatically.
2. After the version is updated the other storage migration we have (MigrateV0ToV1) will no longer be executed as it checks the onchain version which gets set to 1.

I suggest to hold off the rename until MigrateV0ToV1 is executed and optionally move the migration in polkadot-sdk so that we can rely on the version of the pallet to figure out if the migration should be applied or not instead of on a hacks like checking storage keys.

@tdimitrov guessing this was already solved by #490? Or maybe I'm missing something.

@tdimitrov guessing this was already solved by #490? Or maybe I'm missing something.

Not exactly but it looks consistent at the moment so I'm closing this PR.